Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Frequency schema names #46

Merged
merged 6 commits into from
Jan 9, 2024
Merged

Support Frequency schema names #46

merged 6 commits into from
Jan 9, 2024

Conversation

wesbiggs
Copy link
Member

@wesbiggs wesbiggs commented Dec 9, 2023

  • Deploy now uses dsnp.* schema names and new versions of add/propose schema extrinsics.
  • Adds dsnp.getSchemaId() and utility types/methods for registering non-standard mappings (see README.md).
  • New find.ts CLI script will do a forward lookup of DSNP schema names on chain.

cf. frequency-chain/frequency#1784

Updated to use @frequency-chain/[email protected].

Copy link
Collaborator

@aramikm aramikm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks good, some minor comments!

dsnp/index.ts Show resolved Hide resolved
cli/find.ts Outdated Show resolved Hide resolved
dsnp/index.ts Outdated Show resolved Hide resolved
dsnp/index.ts Outdated Show resolved Hide resolved
dsnp/index.ts Show resolved Hide resolved
@JoeCap08055
Copy link
Collaborator

I'm assuming this shouldn't be merged until the next release of PolkadotJS, because the new extrinsics aren't accessible/published in the JS API until then... or at least, that's what I understand from this:

Attempting to create tombstone schema.
TypeError: api.tx.schemas.createSchemaViaGovernanceV2 is not a function
    at createSchemas (file:///Users/joecaputo/src/LibertyDSNP/schemas/cli/deploy.ts:106:39)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async deploy (file:///Users/joecaputo/src/LibertyDSNP/schemas/cli/deploy.ts:41:21)
    at async main (file:///Users/joecaputo/src/LibertyDSNP/schemas/cli/index.ts:3:5)

@wesbiggs
Copy link
Member Author

I'm assuming this shouldn't be merged until the next release of PolkadotJS, because the new extrinsics aren't accessible/published in the JS API until then... or at least, that's what I understand from this:

Attempting to create tombstone schema.
TypeError: api.tx.schemas.createSchemaViaGovernanceV2 is not a function
    at createSchemas (file:///Users/joecaputo/src/LibertyDSNP/schemas/cli/deploy.ts:106:39)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async deploy (file:///Users/joecaputo/src/LibertyDSNP/schemas/cli/deploy.ts:41:21)
    at async main (file:///Users/joecaputo/src/LibertyDSNP/schemas/cli/index.ts:3:5)

It doesn't work on the current release of the Docker image—is that what you mean? I tested against a make start version running locally.

@JoeCap08055
Copy link
Collaborator

I'm assuming this shouldn't be merged until the next release of PolkadotJS, because the new extrinsics aren't accessible/published in the JS API until then... or at least, that's what I understand from this:

Attempting to create tombstone schema.
TypeError: api.tx.schemas.createSchemaViaGovernanceV2 is not a function
    at createSchemas (file:///Users/joecaputo/src/LibertyDSNP/schemas/cli/deploy.ts:106:39)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async deploy (file:///Users/joecaputo/src/LibertyDSNP/schemas/cli/deploy.ts:41:21)
    at async main (file:///Users/joecaputo/src/LibertyDSNP/schemas/cli/index.ts:3:5)

It doesn't work on the current release of the Docker image—is that what you mean? I tested against a make start version running locally.

Ah, actually, I think I misspoke. I believe the PolkadotJS should work fine once the updated chain is deployed (I think it's only the RPC calls that depend on @polkadotjs packages being updated; extrinsics should be fine (@aramikm am I correct?). But this still won't work until the next Frequency release (1.9.1? 1.10.0?) is deployed to testnet & mainnet.

@wesbiggs
Copy link
Member Author

But this still won't work until the next Frequency release (1.9.1? 1.10.0?) is deployed to testnet & mainnet.

Yes, correct, it relies on the new extrinsics/RPC endpoints. We can wait for that before releasing this. (And yeah, let me know what version to watch for.)

Copy link
Collaborator

@aramikm aramikm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

Copy link
Collaborator

@shannonwells shannonwells left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be operator error, but I'm having issues including this branch in a project (@wilwade 's magic-test repo) and using it. It works fine with main branch of schemas.

  1. in this repo + branch: npm link
  2. in test project, npm i @dsnp/frequency-schemas
  3. in test project, run npm link @dsnp/frequency-schemas and verify it's now symlinked to the repo inside of node_modules/@DSNP
  4. Do the import and add the code shown:
import { dsnp } from "frequency-schemas";

const main = async () => {
  console.log(dsnp.getSchema("broadcast"));
}

main().catch(console.error).finally(process.exit);

Then run npm run main to execute the code. It's trying to find parquetjs inside of @dsnp/frequency-schemas:

  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/Users/shannonwells/.asdf/installs/nodejs/18.15.0/.npm/lib/node_modules/@dsnp/frequency-schemas/cjs/parquet.js',
    '/Users/shannonwells/.asdf/installs/nodejs/18.15.0/.npm/lib/node_modules/@dsnp/frequency-schemas/cjs/index.js',
    '/Users/shannonwells/github/magic-test/main.ts'
  ]

README.md Outdated
### Get Schema Id from Chain

```typescript
import { dsnp } from "frequency-schemas";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking: need to prefix with @DSNP

Suggested change
import { dsnp } from "frequency-schemas";
import { dsnp } from "@dsnp/frequency-schemas";

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Committed that change. Was that the issue?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wesbiggs Are you sure you committed the change here? I don't see it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, fixed.

@@ -7,6 +7,7 @@
"test": "jest",
"deploy": "node --loader ts-node/esm cli/index.ts",
"read": "node --loader ts-node/esm cli/read.ts",
"find": "node --loader ts-node/esm cli/find.ts",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Find works against a local chain.

Wes Biggs added 3 commits January 3, 2024 15:26
* Deploy now uses `dsnp.*` schema names and new versions of add/propose schema extrinsics..
* Adds `dsnp.getSchemaId()` and utility types/methods for registering non-standard mappings.
* New find.ts CLI script will do a forward lookup of DSNP schema names on chain.
@wesbiggs wesbiggs force-pushed the feature/schema-names branch from 11b9e21 to 40db31e Compare January 3, 2024 21:27
@wesbiggs wesbiggs enabled auto-merge (squash) January 3, 2024 21:33
console.log("SUCCESS: " + schemaName + " schema created with id of " + val);
resolve({ schemaName, id: Number(val.toHuman()) });
} else resolve({ schemaName });
const id = evt?.data[1];
Copy link
Collaborator

@enddynayn enddynayn Jan 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe not a big deal for your purposes but do you need to close the subscription?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so, for correctness. Probably doesn't matter too much since it's a run-and-done CLI program, but I wouldn't be surprised if there are some error logs that come out when the program is done that would be cleaned up with an unsub() call. I'll pull this branch and see...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see no errors when I run; like I said, probably not a critical issue since this is CLI run-and-done. Fix if you like; non-blocking.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we're actually subscribed here -- if the event is not immediately in the block or finalized, it looks like we never resolve or reject the Promise. Obviously this seems to work fine in an ideal environment (especially one with instant sealing) but I don't think it handles edge cases or busy chains very well.

I'd prefer to make that a separate issue though as it's a pre-existing condition, and maybe someone slightly more familiar with how to subscribe and poll could add this or give me some pointers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added as #49

cli/deploy.ts Outdated Show resolved Hide resolved
@wilwade wilwade requested a review from shannonwells January 4, 2024 18:14
Copy link
Member

@wilwade wilwade left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢

  • Ran locally
  • Tested with docker

Copy link
Collaborator

@shannonwells shannonwells left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks

@wesbiggs wesbiggs merged commit 0bcd42f into main Jan 9, 2024
1 check passed
@wesbiggs wesbiggs deleted the feature/schema-names branch January 9, 2024 01:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants